home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fritz: All Fritz
/
All Fritz.zip
/
All Fritz
/
FILES
/
PROGNG_C
/
M2DOC.LZH
/
FMODULA2.DOC
< prev
next >
Wrap
Text File
|
1987-07-06
|
70KB
|
2,509 lines
Modula-2 Compiler
(C) Copyright 1987 Fitted Software Tools.
All rights reserved.
Fitted Software Tools
P.O.Box 956129
Duluth, Ga 30136
DISCLAIMER OF WARRANTY
THIS SOFTWARE AND MANUAL ARE PROVIDED "AS IS" AND WITHOUT
WARRANTIES AS TO PERFORMANCE OR MERCHANTABILITY.
THIS SOFTWARE IS PROVIDED WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES WHATSOEVER. BECAUSE OF THE DIVERSITY OF
CONDITIONS AND HARDWARE UNDER WHICH THIS SOFTWARE MAY BE
USED, NO WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE IS
OFFERED. THE USER IS ADVISED TO TEST THIS SOFTWARE
THOROUGHLY BEFORE RELYING ON IT. THE USER MUST ASSUME THE
ENTIRE RISK OF USING THIS SOFTWARE.
IBM is a registered trademark of International Business
Machines Corporation.
- 1 -
Chapter 1
Introduction
Thank you for your interest in our Modula-2 compiler.
This system features a Modula-2 compiler with an integrated
editor and "make" facility, a program linker, a makefile
generator, and an execution profiler.
The compiler generates code for the Intel 8086 "huge" memory
model: Each module has its own data and code segment, each
of which can be up to 64k in size; pointers are four bytes
long. More restrictive memory models are not currently
supported.
All the library and runtime support source code is provided
to our registered users (see Shareware).
We hope that our effort will prove itself worthy of your
support.
Introduction 2
1.1 Hardware requirements
This system will run on IBM PC, PC/AT, or compatible systems
with at least 512K of RAM, two double sided floppy disk
drives and a monochrome display adapter, color graphics
adapter or equivalent.
For best performance, a hard disk and 640K of RAM are
recommended.
1.2 Software requirements
This system will run under DOS version 2.0 or later.
No other software is required to use this system, but you
will need an assembler if you intend to modify one of the
runtime support modules: M2Reals (floating point support),
M2Longs (LONG arithmetic) or M2Procs (coroutine handling).
Introduction 3
Chapter 2
Software installation
2.1 Theory
The library module Terminal requires that the ANSI.SYS
driver be installed.
The executable files (MC.EXE, M2LINK.EXE, ...) should, for
ease of operation, be placed in a drive/directory named in
the DOS PATH variable.
The editor configuration file M2ED.CFG must be accessible
through the DOS PATH variable.
Both the compiler and the linker will use the environment
variable M2LIB to locate required library modules (the
format for the M2LIB entry matches that of the DOS PATH).
The compiler and utilities in this package do not keep many
files open simultaneously. If you set the FILES parameter
in CONFIG.SYS to 10 you should not encounter any problems.
For performance considerations, you should also allocate
more than the default number of buffers for DOS: If you are
running on a PC class machine, try allocating 20 buffers in
your CONFIG.SYS. On an AT type machine, try 64 buffers.
Example CONFIG.SYS:
DEVICE=ANSI.SYS
FILES=10
BUFFERS=20
This compiler is a memory hog (you heard it here first!).
Therefore, unless you have 640k of memory installed in your
system, you should have COMMAND.COM available for reload
once you exit the compiler.
If you have 640k of memory, you will probably want to enable
the "COMMAND save" feature of the compiler, which will stop
it from clobbering the resident portion of COMMAND.COM. Just
add the following line to your AUTOEXEC.BAT file:
SET CMDSIZE=NN
where NN is the size of the resident portion of COMMAND.COM
Software installation 4
in K (18 for DOS 3.0).
MC clobbers the top of the memory space available for use
during initialization. Therefore, to find out the size of
the resident portion of COMMAND.COM try the following
procedure: start by setting CMDSIZE to the size of
COMMAND.COM. If now you execute MC, exit it, and press the
F3 key, DOS will still remember your MC command. Decrement
CMDSIZE and retry the MC test until the system forgets your
last command (COMMAND.COM had to be reloaded).
2.2 Recommended setup for a system with 2 floppy drives
This whole system is too large to fit in a single 360k
floppy. Therefore, it is recommended that you build a
"compiler" floppy and a "utilities" floppy (you may combine
them both in a 720k or 1.2Mb floppy).
On the compiler floppy, place the compiler (MC.EXE), all the
library definition modules (*.DEF) and the file M2ED.CFG.
The utilities floppy will take all the rest: the linker
(M2LINK.EXE), other .EXE files, and the library and runtime
support object files (*.M2O and *.BIN).
Assuming that you will use drive A for the compiler and
utilities disk and drive B as your work drive, add the
following to your AUTOEXEC.BAT file:
SET PATH=A:
SET M2LIB=A:
Software installation 5
2.3 Recommended setup for a hard disk system
Place the executable files (*.EXE) and M2ED.CFG in a
directory currently in the DOS search path, or in a new
directory (ex: \MODULA2) to be added to the PATH list.
Example:
SET PATH=C:\BIN;C:\MODULA2
Make a directory for the library files (ex: \M2LIB) and copy
all the .DEF, .M2O and .BIN files to it. To the
AUTOEXEC.BAT file add the line:
SET M2LIB=C:\M2LIB
You will probably want to create a directory for your own
reusable library modules. This directory can be added to
the M2LIB environment variable. Example:
SET M2LIB=C:\M2LIB;C:\MYLIB
You may keep your projects in their own, individual,
directories.
Software installation 6
Chapter 3
A little tour through the system
After you finish the installation as described above, you
are left with a few .MOD files. These are the example
programs. Please copy them to your work disk or directory.
First, we will look at the unnatural case of compiling,
linking and running a program that works the first time
around. Please execute the following commands:
MC SIEVE /C
M2LINK SIEVE /O
Well, that's it! Ready to run...
SIEVE
Now for the more usual case:
MC BADSIEVE
From the compiler menu, select 'C' for compile.
Gee, that was quick! Press RETURN to take a look at our
errors...
The cursor is now positioned at the location of the first
error. Using the keys Ctrl-E (find next error) and Ctrl-P
(find previous error) you may visit all the errors flagged
by the compiler. All the while, the editor shows the error
description on the top line of the screen. But, going back
to the first error...
We really confused the compiler when we mistakenly typed in
'.' instead of '..' in the range declaration. Move the
cursor back (left arrow key) to where the '.' is, type in
another '.', and that should fix that! As you will see as
you type Ctrl-E, that single error caused the compiler to
dislike a few other things on that same line; we will just
ignore those errors and go on.
Go on to the next error location (line 22). This time, we
should have used a ']' but typed '}' instead. The backspace
key will delete the offending character; now, type the ']'
in its place.
And that is that. Shall we try to compile the program
A little tour through the system 7
again?
Press Alt-S to save the file, Alt-Q to leave the editor and,
back at the main menu, select 'C'.
More errors?!
These errors should have been detected during pass2 of
the compiler; If not, you may try to fix these errors
and recompile, or you may opt for loading and compiling
the new file BADSIEV1.MOD, which contains the earlier
fixes.
Going back to the editor...
We find that we used the identifier 'cnt' which is
undefined; we really meant to use count. So, moving the
cursor around with the cursor keys and/or deleting
characters with the backspace or delete key, please replace
'cnt' by 'count'.
Searching for the next error...
The next error occured during the processing of the call to
WriteCard. What happened here is that WriteCard requires 2
parameters, the second one being the size of the field to
display. So, to fix it, let's insert a comma after 'count'
and some number (for example 'count,4').
Any more erors? No, that is it...
We now save the file (Alt-S), quit the editor (Alt-Q) and
recompile (c).
Now, the program should have compiled without errors. If
not, you may recompile BADSIEV2.MOD instead.
We may now quit the compiler (q).
By now, we have some program that has compiled clean
(BADSIEVE, BADSIEV1 or BADSIEV2). In what follows, we will
assume all went well and we have BADSIEVE.
If you look at the directory, you will see the new object
module created as a result of the previous exercise
(BADSIEVE.M2O). The compiler always writes its output to a
file with the extension 'M2O'.
Let us link and test the program:
M2LINK BADSIEVE /L
We use the /L option so that the line number information
written out by the compiler to the object file will be
preserved by the linker. We will need this information
later.
A little tour through the system 8
BADSIEVE
A runtime error? And it gives us a PC location. Very
informative, is it not? How in the world are we supposed to
fix the program based on that? Do not dispair!
Looking at your directory, you will notice that the linker
created 2 files: BADSIEVE.EXE and BADSIEVE.DBG.
No, TYPEing BADSIEVE.DBG does not help, it just displays
garbage. But we have a utility called DBG2MAP that will
convert the information in that file to a DOS LINK
compatible MAP file. Let's try it:
DBG2MAP BADSIEVE
Now, using your favorite editor (or the editor in MC: MC
BADSIEVE.MAP and then E), look at the contents of
BADSIEVE.MAP. In the last few lines of the file, we have the
line number information for BADSIEVE. If you look up the
line whose address is closest (but lower) to the PC in the
error message, you get the number of the line where the
error occured (line 22).
Let's see what happened...
MC BADSIEVE
Pick 'E' to go into the editor and, either move the cursor
down to the line indicated by your research, or let the
editor find it with Alt-G.
So, what is the problem? Well, we declared the 'flag' array
to have a maximum index of 8190, but 'j' got bigger than
that (the FOR loop will increment 'j' up to the value of
10000).
You may fix the problem by deleting the '10000' and typing
in its place 'SIZE'.
Recompile the program, link it, and run it. Did it work?
Good.
It is time for you to experiment on your own. But, before
you do much more, you may want to check out the Editor
chapter of the documentation.
A little tour through the system 9
Chapter 4
The Compiler
In Modula-2, identifiers may be used before they are
declared, except when they are used in another declaration
(this restriction does not apply to pointers). This forces
the compilation process to be done in at least two passes.
To avoid imposing unnecessary restrictions and, yet, provide
reasonable performance, the two pass approach was selected:
During the first pass, syntax analysis and declaration
analysis are performed; The second pass performs the
semantic analysis and code generation.
The compiler has an integrated text editor. Should errors
be encountered, the editor is invoked at the end of the
current compiler pass (sooner, if an error is found during
the processing of an import list or if 20 errors are
identified).
The compiler also has a built in "make" processor. A
makefile must be created before this process is invoked.
Although you can create a makefile using the editor, we
recommend that you use the utility provided for that
purpose: GENMAKE.
The Compiler 10
4.1 Running the compiler
Compiler invocation:
MC [myprog] [/c]
If the compiler is invoked without the '/c' option, you will
get a screen that looks something like this:
Modula-2 compiler, Version 1.0
(C) Copyright 1987 Fitted Software Tools.
All rights reserved.
Editor Heap in use: 18K
Available Heap: 216K
Work module: myprog.MOD
New Compile Edit Make Quit >
The options at this point are:
New Specify another "Work module".
Compile Compile the "Work module".
Edit Edit the "Work module".
Make Recompile all the necessary modules as per
the rules of a makefile (you will be prompted
for the makefile). Note: If errors are
encountered during the compilation of one of
the modules, the make process is aborted!
Quit Return to DOS.
If you use of the '/c' command line option, the compiler
starts compiling "myprog" immediately and, if no errors are
encountered, will bring you right back to the DOS prompt.
This is useful when running the compiler from a batch file:
MC myprog /c
The compiler sets the DOS errorlevel to 0 if the last
compile was successful (no errors); otherwise, the DOS
errorlevel is set to 1.
The Compiler 11
4.2 The compilation process
4.2.0.1 The input file
If the module to be compiled is already loaded into one of
the editor buffers, that source is compiled. Otherwise, the
compiler tries to open the named file.
4.2.0.2 The imported modules
The compiler and the linker cooperate in assuring that all
the modules that refer to a particular definition module
will have been compiled against the same version of that
definition module.
To this end, the compiler places in the 'module header' and
'module import' records of the object file a "module key".
This module key is the date of the DEF file used during the
compilation of the implementation module or during the
processing of the IMPORT statement.
Due to this, the compiler will not look in the editor
buffers for the DEF files needed to process an IMPORT list.
These are always read in from the disk.
4.2.0.3 The output file
The output from the compilation of a main module or an
implementation module is a single output file, with the same
name of the source file but with the extension of 'M2O'
(Modula-2 Object).
The compilation of a definition module does not generate any
new output files. If the compilation is successful (no
errors), the compiler simply 'touches' the source file,
updating its modification time.
4.2.0.4 A warning
Because of the fact that the compiler uses the date of the
The Compiler 12
DEF file as that module's key, you may not modify a DEF file
unless you intend to recompile all the modules that use it,
nor can you copy the file in such a way that its date is not
preserved.
In particular, if you are going to be transferring your
modules between computers, you must use some procedure that
will preserve all the DEF files' dates.
4.3 Compiler directives
Certain compiler code generation options may be set through
directives included in the program text. These directives
must appear immediately at the beginning of a comment;
multiple directives may be entered in a single comment by
separating them by commas. Example
(* $S-, $R+ *)
A '+' sets the directive to TRUE, a '-' sets it to FALSE.
The following compiler directives are defined:
$A Alignment. Default $A+. If enabled, all new
variables declared are aligned on a word
boundary. Record fields are packed (not
aligned) regardless of the setting of this
option.
$S Stack overflow checking. Default $S+. If
enabled, stack overflow checking is performed
on entry to a procedure and when copying open
arrays to a procedure's local stack frame.
$R Range checking. Default $R+. If enabled,
before any assignment is made to a variable
of a subrange type, the value to be assigned
is tested against the limits of the subrange
type.
$T Array subscript checking. Default $T+. If
enabled, any time a subscript operation is
performed on an array, the subscript value is
checked to confirm that the operation would
not generate an address outside the bounds of
the array.
$L Generate line number information. Default
$L-. If this option is enabled, the compiler
will include a list of source code line
numbers and their corresponding object code
The Compiler 13
offsets in the output file. This line number
information is passed on to the .DBG file
when the program is linked with the /L
option.
4.4 Runtime errors
When, during the execution of a program, a runtime error is
detected, the runtime error handler will terminate the
program and write out a message indicating the type of error
encountered and its location (PC address).
To find the location of the error in the source code, run
DBG2MAP against the .DBG file generated by M2LINK for this
program. Scanning the .MAP file created, you should be able
to always determine the module and procedure where the error
occured. If the $L+ directive was used when compiling the
module in question and the /L option was used when linking
the program, the error location can be pinpointed to the
offending line by scanning the line number information at
the end of the .MAP file.
4.4.1 Trapping runtime errors in your program
The Library module System provides you with a means of
intercepting runtime errors. The following are the
currently defined runtime error numbers that may be passed
to your error handler routine:
0 stack overflow ($S option)
1 range error ($R or $T option)
2 integer/cardinal overflow (divide by zero)
3 floating point error
4 function did not execute a RETURN
5 HALT was invoked
4.5 Compiler size limits
The following are the code and data size limits imposed by
this compiler:
- A string constant cannot exceed 80 characters. This is
also the limit set for the size of any identifier.
The Compiler 14
- Each compilation module is assigned its own data
segment, which can be up to 64k in size. In the data
segment, the compiler allocates the space for all the
module's global variables and some of the module's
constants.
- The maximum size of a data structure is 65532 bytes.
- The maximum amount of space allocated for variables
local to a procedure is 32000 bytes.
- The compiler will also refuse to generate the code to
pass, in a procedure call, by value, a parameter
greater than 65000 bytes in size.
The following are the compiler's internal limits:
- The maximum number of different (namewise) identifiers
that can be processed in a single compilation is 2000.
- The total number of characters in all the different
(namewise) identifiers processed cannot exceed 8000
characters.
- No single procedure can be translated into more than
10k of object code.
- An array of 8k bytes is used to keep track of all the
initialized data for a module. This imposes a limit on
the total amount of string, real and long constants
used in the compilation module.
4.6 The language supported
This release of the compiler will translate a program
written in the Modula-2 language as defined by Niklaus Wirth
in the 3rd edition of his book "Programming in Modula-2",
with the exceptions noted bellow:
- Integer and Cardinal arithmetic overflow is not
detected.
- Module priority specifications are not allowed.
- ASM is a reserved word in this implementation.
- For those programmers that "grew up" in the Hex world,
a way to define CHAR literals in Hex is provided: 20X
corresponds to the "space" character in ASCII.
The Compiler 15
4.6.1 LONGINT and LONGCARD
This compiler implements the standard types LONGINT and
LONGCARD.
Operands of the type LONGINT or LONGCARD may appear in any
expression, just like INTEGER or CARDINAL. But that is about
it!
Subranges of these types are not supported.
No standard procedure (like INC, DEC) except the ones listed
later in this document will accept operands of one of these
types.
A variable of type LONGINT or LONGCARD cannot be used as the
control variable in a FOR loop. Neither can CASE labels be
of a LONG type.
Constants of type LONGINT or LONGCARD can be coded in
decimal only and are terminated by an 'L'. Example
123L is a valid LONGCARD or LONGINT constant
-348762L is a valid LONGINT constant
565656 -89076 are CARDINAL and INTEGER constants out of
range
4.6.2 Additional standard procedures
4.6.2.1 NEW and DISPOSE
NEW and DISPOSE have been deleted from the language
definition in the 3rd edition of Wirth's book. We implement
them thus:
NEW(p)
Invokes the procedure ALLOCATE, which must conform to the
type:
PROCEDURE ( VAR ADDRESS, CARDINAL )
passing along p and the size of the object p is defined as
pointing to.
DISPOSE(p)
Invokes the procedure DEALLOCATE, which must conform to the
type:
PROCEDURE ( VAR ADDRESS, CARDINAL )
The Compiler 16
passing along p and the size of the object p is defined as
pointing to.
The procedures ALLOCATE and DISPOSE must, therefore, be
defined in the module using NEW and/or DISPOSE, or imported
from some other module, like Storage.
4.6.2.2 LONG and SHORT
PROCEDURE LONG( INTEGER ) :LONGINT;
PROCEDURE LONG( CARDINAL ) :LONGCARD;
PROCEDURE SHORT( LONGINT ) :INTEGER;
PROCEDURE SHORT( LONGCARD ) :CARDINAL;
LONG takes an INTEGER (CARDINAL) and converts it into a
LONGINT (LONGCARD).
SHORT takes a LONGINT (LONGCARD) and converts it into an
INTEGER (CARDINAL).
4.7 Objects exported by the pseudo module SYSTEM
4.7.0.1 TYPE BYTE
Takes 1 byte of storage. Only assignment is defined for
this type. If the formal parameter of a procedure is of
type BYTE, the corresponding actual parameter may be of any
type that takes 1 byte of storage.
If the formal parameter of a procedure is of type ARRAY OF
BYTE, the corresponding actual parameter may be of any
type.
4.7.0.2 TYPE WORD
Takes 1 word (2 bytes) of storage. Only assignment is
defined for this type. If the formal parameter of a
procedure is of type WORD, the corresponding actual
parameter may be of any type that takes 1 word of storage.
If the formal parameter of a procedure is of type ARRAY OF
WORD, the corresponding actual parameter may be of any
type. Care should be taken in this case, as the size of the
parameter passed is rounded up to an even size.
The Compiler 17
4.7.0.3 TYPE ADDRESS
The type ADDRESS is compatible with all pointer types.
ADDRESS itself is defined as a POINTER TO WORD. In this
implementation, the type ADDRESS is not compatible with any
arithmetic type. This is due to the fact that the Intel
8086 series processors use segmented addresses. It would
not be hard to implement automatic conversions between
LONGCARD and ADDRESS but it is felt that this would be
contrary to the spirit of the language, whereby the compiler
is not expected to perform any "magic" tricks. Instead, two
functions are provided for that purpose: FLAT and PTR.
4.7.0.4 SEG and OFS
These are field definitions for POINTER types. If you
import these you may access the segment or offset portions
of a pointer variable using regular field selection syntax.
Example
pointer.SEG :segment portion of pointer
4.7.0.5 PROCEDURE ADR
ADR( designator ) Returns the address of designator (type
ADDRESS).
4.7.0.6 PROCEDURE FLAT
FLAT( ADDRESS ) returns a LONGCARD "flat" address.
4.7.0.7 PROCEDURE PTR
PTR( LONGCARD ) returns an ADDRESS corresponding to the
"flat" address represented by the LONGCARD.
4.7.0.8 PROCEDURE NEWPROCESS
NEWPROCESS(p:PROC; a:ADDRESS; n:CARDINAL; VAR p1:ADDRESS)
creates a new process whose entry point is p and workspace
is at a for n bytes. p1 is the new process pointer. This
process is not activated until a TRANSFER to p1 is done.
4.7.0.9 PROCEDURE TRANSFER
TRANSFER( VAR p1, p2 :ADDRESS)
suspends the current process, assigning it to p1 and resumes
The Compiler 18
p2. The current process' value is assigned to p1 only after
p2 has been identified; it is, therefore, okay for p1 and p2
to be the same.
4.7.0.10 PROCEDURE IOTRANSFER
IOTRANSFER( VAR p1, p2 :ADDRESS; intVector :CARDINAL )
issues a TRANSFER from p1 to p2 (just the way TRANSFER does
it) after installing the current process for reactivation
when an interrupt comes in through interrupt vector
intVector.
When the interrupt occurs, the interrupt vector is reloaded
with its previous value. A TRANSFER is done to the I/O
process (the one that issued the IOTRANSFER) such that p2
now contains the value of the process that was running when
the interrupt occured.
4.7.0.11 ASSEMBLER
An 8086 inline assembler is provided. Once ASSEMBLER is
imported from SYSTEM, you can enter inline assembler code by
bracketing it with the keywords ASM and END.
Assembler input is free form. Comments are entered as in
regular Modula-2. Example
loop: CMP BYTE [SI], 0 (*end of string?*)
MOV BYTE [DI], [SI]
INC SI INC DI (*increment pointers*)
JMP loop
The assembler accepts all the 8086/8088 opcode mnemonics.
Address operands can be coded in just about any form
acceptable to other assemblers, except that the only
operator supported if '+'. Operand type overrides are: WORD,
BYTE, FAR, NEAR and are not to be followed by the keyword
POINTER or PTR. Example
label: MOV AX, ES:[BX,DI+5]
MOV AX, ES:5[DI+BX]
MOV WORD [5], 1
CALL NEAR [DI]
TEST BYTE i+2, 1
All the mnemonics and register names must be entered in
upper case. In case you need to use a Modula-2 name that
conflicts with one of the assembler reserved symbols, you
may precede it with a '@'. Example
MOV @AX, AX
would generate a move from register AX to variable AX.
The Compiler 19
All modula-2 variables can generaly be accessed in
assembler. Record field names are not accessible from
assembler. The assembler will not automatically do anything
for you. For example: if you specify a VAR parameter as an
operand to an instruction, you are naming the address of the
pointer to the actual parameter. Example
PROCEDURE p( VAR done :BOOLEAN );
...
ASM
LES DI, done
MOV BYTE ES:[DI], TRUE
END;
is the correct way of storing TRUE in done.
The following types of constants may be accessed in
assembler: INTEGER, CARDINAL, BOOLEAN, CHAR and enumeration
constants.
All labels declared inside an ASM section are local to that
section of code. But labels names cannot match some name
known in the scope of the current procedure. Labels can
only be referenced in jump instructions.
All jumps are optimized by the compiler. There is,
therefore, no need (or capability) to specify the size of a
jump. In particular, the compiler will turn a conditional
jump out of range into a reverse conditional jump over a far
jump to the original destination.
Remember, this is a Modula-2 compiler, not an assembler!
The inline assembler capability is provided for use in
exceptional situations only.
4.8 The generated object code
4.8.1 Data type representation
CHAR 1 byte
INTEGER 2 bytes 2's complement
CARDINAL 2 bytes
LONGCARD 4 bytes
LONGINT 4 bytes 2's complement
The Compiler 20
BOOLEAN 1 byte (1=TRUE, 0=FALSE)
REAL 4 bytes Intel 8087 format.
BITSET 1 word. 0 is low order bit, 15 is high order
bit.
Enumerations 1 byte
SETs 1 to 8 words (sets of up to 256 elements)
POINTERs 4 bytes in Intel 8086/88 format
PROCEDUREs 4 bytes POINTER to procedure entry point
Addresses are represented in the default Intel 8086 format:
1 word byte offset
1 word segment
Numeric values are likewise represented the way the Intel
8086 processor family likes them: low order byte first, high
order byte last.
4.8.2 The runtime memory map
Currently, the compiler generates code using the "huge"
memory model only. Each module has its own data and code
segments. The linker binds all the code segments first, and
then all the data segments. The stack is allocated above
the data segments. All the remainning memory is available
for the heap.
When a program is loaded for execution, here is what the
memory looks like:
From low to high addresses:
0 ----------------------------------------------
I Interrupt vectors I
I DOS I
PSP I Program segment prefix I
PSP+100h I Program Code segments I
I Program Data segments I
StackSeg I Stack I
HeapTop I Heap I
I ... I
I DOS Command (resident portion) I
MemTop ----------------------------------------------
Label names on the left are the ones exported by System.
The Compiler 21
This system uses interrupt vector 192 (0C0H) at location
0000:0300. Interrupt 192 is issued by a program when a
runtime error occurs, when HALT is invoked or when a
coroutine other than the main one terminates via a return.
The first word (offset 0) in every code segment contains the
data segment value for that particular module.
4.8.3 Procedure calling conventions
Procedure parameters are pushed into the stack 1st argument
first. Control is then transferred to the procedure through
a FAR call. It is the called procedure's responsibility to
remove its parameters from the stack before returning.
4.8.3.1 Parameter passing (all except open array parameters)
If the formal parameter of a procedure is a value parameter,
the actual parameter is copied into the stack.
If the formal parameter is a variable parameter (VAR), the
address of the actual parameter is pushed into the stack
(first the segment portion of the address and then the
offset part).
4.8.3.2 Parameter passing (open array parameters)
If the formal parameter is an open array, the address and
HIGH value of the corresponding formal parameter are pushed
into the stack (HIGH value first, and then the address, as
above).
If the open array parameter is a value parameter, the value
of the actual parameter is copied into the stack on
procedure entry.
The Compiler 22
Chapter 5
The Text Editor
The text editor included in this package has all the
features that you have come to expect from a basic program
editor: the ability to insert, delete, move, find and
replace text; support for concurrent editing of multiple
files (as many as will fit in memory) in separate windows
(as many as will fit on the screen) with the ability to copy
or move text from window to window.
Although you may load the same file in two different
windows, the editor will not be aware of the fact and will
treat the two copies as two different files.
The only preset limitation in the editor is that it cannot
handle files bigger than 64k. This decision was justified by
the fact that Modula-2 programs are supposed to be modular.
File load/save speed was the overriding factor here.
All the text editor keys are defined by the user through the
use of the EDCONFIG program. When the editor starts, it
expects to find the file M2ED.CFG in the current PATH.
To get you started, we provide a M2ED.CFG file with the
following definitions:
Cursor left : Left
Cursor right : Right
Cursor up : Up
Cursor down : Down
Previous word : ^Left
Next word : ^Righ
Page up : PgUp
Page down : PgDn
Cursor to beginning of line : Home
Cursor to end of line : End
Cursor to top of window : ^Home
Cursor to bottom of window : ^End
To beginning of file : ^PgUp
To end of file : ^PgDn
Current line to top of window : AltT
Toggle insert/overtype : Ins
Delete character under cursor : Del
Delete previous character : ^H
New file : AltN
Read file : AltR
Write block : AltW
The Text Editor 23
Save file : AltS
Open window : ^O
Close Window : ^C
Next window : F2
Previous window : aF2
Split screen : ^S
Mark beginning of block : F7
Mark end of block : F8
Goto beginning of block : AltB
Goto end of block : AltE
Clear block marks : AltH
Copy block : AltC
Delete block : AltD
Move block : AltM
Search forward : F5
Search backwards : aF5
Replace forward : F6
Replace backwards : aF6
Global replace : ^F6
Repeat last search/replace : F1
Goto next error : ^E
Goto previous error : ^P
Goto line : AltG
Set options : AltO
Redraw the screen : ^L
Quit : AltQ
The Text Editor 24
Chapter 6
The Linker
The linker is invoked by the command line
M2LINK myprog [/s n] [/h n] [/o] [/p] [/l]
where 'myprog' is the main module of the program you
are creating. The options are thus:
/s n n is the size of the stack to allocate
(default is 4096).
/h n n is the amount of space to reserve for
the heap (in paragraphs). The default is
all the free memory.
/o invokes the optimizer. The optimizer
prevents the output, to the object file,
of all the procedures that are part of
included modules but are not referenced.
This will make your final EXE files
smaller.
/p tells the linker to include the profiler
(M2Prof.M2O). For further information,
see the chapter on "Utilities".
/l tells the linker to process the line
number information in the .M2O files and
include it in the .DBG file. This option
is disabled if the optimizer is invoked.
/k tells the linker to ignore module keys,
i.e. to not check for module version
compatibility. This option should be
used with extreme care.
The linker creates two files: the .EXE file is your
executable program, the .DBG file is a file containning
symbol information for use by other utilities (see Map file
generator, Profiler).
The Linker 25
6.1 Module keys
The module header record and the import records written out
by the compiler to the object file are stamped with the date
of the .DEF file that was processed - this becomes the
module key. The linker will assure that these module keys
in the module header of the imported module and in the
import record match; If they do not match, both modules were
not compiled using the same definition module.
Because of the use of module keys, it is imperative that the
date of the distributed .DEF files not be modified unless
you intend to recompile the implementation modules.
The Linker 26
Chapter 7
Other utilities
7.1 Editor keyboard configurator
This program lets you define the keystrokes to be used to
invoke all the editor commands.
Invokation:
EDCONFIG
You will be prompted for a log file (default M2ED.HLP), a
text file in which all of your configuration choices will be
saved. You could print this file to create a quick
reference card.
EDCONFIG will then prompt you for the key sequence to be
used for each editor command. For each command, EDCONFIG
will also give you the option of defining an alternate key
sequence.
Once you have run through all the commands, the program will
prompt you for an output file, the default being 'M2ED.CFG'.
7.2 Map file generator
Invokation:
DBG2MAP module_name
Reads the .DBG file created by M2LINK and creates a DOS LINK
compatible .MAP file.
Other utilities 27
7.3 Make and the Makefile generator
These utilities eliminate the burden, on the user's part, of
having to figure out which modules are affected and,
therefore, need to be recompiled as a result of any changes
to particular definition modules.
GENMAKE creates the .MAK file, the file with all the
dependencies (this is the hard part) whereas MAKE (built
into the compiler) will insure that these dependencies are
observed when updating the object files.
GENMAKE Invokation:
GENMAKE main_module_name
generates the .MAK file containning all the module
dependencies for the named program. It does this by reading
all the IMPORT statements in the main module and,
recursively, generating the dependency lists for all those
modules (but only the ones that can be found in the current
directory!). GENMAKE will indeed read all the .MOD and .DEF
files involved.
MAKE invocation: see "Running the Compiler".
MAKE will invoke the compiler as needed to assure that all
the dependencies in the make file are observed. MAKE is
dumb in that it will just run through the makefile
sequentially. It was GENMAKE's responsibility to see that
the dependencies are listed in a proper sequence. Please
keep this in mind if you should edit a makefile!
7.4 The execution profiler
When you link your program with the /p option, the module
M2Prof is included in the output generated.
When you execute the program, the profiler will ask you for
the name of the .DBG file to use and give you an option of
profiling your entire program (generating an execution
profile by module), a particular module (generating an
execution profile by procedure in that module) or a
particular procedure (generating an execution profile by
line in the procedure).
Other utilities 28
Upon program termination, the profiler outputs the list of
all the modules/procedures/lines profiled, ranked by
execution time, to a file of your choice.
This profiler is not that versatile, but it is useful
nevertheless. It proved instrumental in pinpointing some
obvious areas for improvement in the compiler (Oh, we did
not tell you, did we? This compiler was written in the
language it compiles -- Modula-2 -- and this system was used
as our primary development tool since very early in the
development process).
Other utilities 29
Chapter 8
The Library Modules
For complete information on what each library module
provides, as well as its proper usage, please look at the
.DEF files.
In addition, the source code of all the library modules is
available to all the registered users (see the order form in
the back of this document for details).
The Library Modules 30
Chapter 9
Shareware
This software package is distributed under the "user
supported" concept.
This software can be freely distributed, as long as no money
is charged for it, all the files are included, unmodified,
and with their modification dates preserved. If you are
going to place this software on a bulletin board (we thank
you for it), please upload it in a library format (we
suggest ARC) that will preserve this package's integrity.
This software cannot be distributed as a part of, or in
conjunction with, another product.
This software cannot be used in a commercial environment
without the payment of a $25 license fee per copy. Please
feel free to contact us if you would be interested in a site
or corporate license.
The "user supported" form of distribution can be in the best
interest of all concerned, if we consider the following: (1)
users are given the opportunity to try, without pressure,
the software to determine its suitability for some intended
purpose; and (2) we eliminate the high cost of publishing
and advertising (our users do it for us) and can, therefore,
provide the same product for less.
Our success will depend not only on the quality of this
software but on the willingness of every individual user to
"support" its developers.
If you use this product, please send in the registration
form in the back of this document, along with your
registration fee. For $35 we will send you the latest
version of this software and, as a token of our
appreciation, all the library and runtime support source
code (what a bargain!). This source code is made available
to registered users only!
Whether or not you decide to use this product, please give
complete copies of this software to others (the more the
better). You are an integral part of our distribution
channel!
Shareware 31
Chapter 10
Your input matters to us
You can bet that this is serious! We know, and you know,
that there are many ways in which this system can be
improved. It is in our common interest that we agree on
just how (what needs changing, what additional capabilities
are needed) and when (let's take care of the more important
stuff first!).
Maybe you like this software so much that you would hate to
see us improve it in the wrong direction (ha, ha, ha)...
Maybe you find some weaknesses in this product that make it
awkward to use.
Maybe even (God forbid!) that one or more of those
weaknesses make this software unusable for your purposes.
Whichever the case may be, we need to know about it, our
future is at stake!!!
So, please!, fill out the survey form and send it in.
Your input matters to us 32
Your comments would be appreciated
Where did you get this software from?
( ) us ( ) a bulletin board
( ) a friend ( ) a computer club
( ) a shareware software distributor
( ) other ________________________
Systems you intend to use this software on
( ) PC (8088/8086) ( ) AT (80286) ( ) 80386
Typical system's configuration
( ) hard disk
( ) 512k ( ) 640k
( ) extended memory
( ) EGA adapter
( ) VGA adapter
What programming languages do you use regularly?
---------------------------------------------------------
Please rate the relative desirability of the following. Most
desirable gets a 1, second gets a 2, etc. Could care less gets a
0. Immediate requirement gets an *.
Documentation
( ) language tutorial to be included in the documentation
( ) complete language reference manual
( ) other:
_________________________________________
The compiler
( ) compatibility switch to accept 2nd edition Modula-2
( ) symbolic debugger
( ) improved space efficiency
( ) improved compiler speed
( ) ability to create .OBJ files
( ) inline 8087/80287 code generation
( ) floating point library to detect presence of 8087/80287
( ) code generation for the 80286 (in real mode)
( ) code generation for the 80386 (real mode or V8086)
( ) additional memory models - only one available is huge
( ) tiny ( ) small ( ) medium ( ) compact ( ) large
The editor
( ) support for EGA modes
( ) mouse based editor (in graphics mode)
Integration:
( ) availability of freestanding editor
( ) availability of freestanding compiler
( ) add more integrated tools:
_______________________________________
_______________________________________
How could we improve the compiler?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
What features would you like to see in the editor?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
How could we improve the development environment?
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
_____________________________________________________________
Other comments:
BUG REPORT
We would like to think that our software is bug free, but we
have been around a while. Someone once wrote that a bug
free program is a program whose bugs have not been uncovered
yet.
So, if you uncover one of those nasty critters, please
provide us with the information below, and whatever else
that may help us duplicate the problem.
Name_____________________________________________
Company__________________________________________
Address__________________________________________
City, State, Zip_________________________________
Telephone _____________
Version of the software in use: ___________________________
Machine in use (make and model): ___________________________
Memory / Disks / Display type: ___________________________
Operating system used: ___________________________
Other system information that may be pertinent (PATH
settings, CONFIG.SYS contents,...)
Problem description:
ORDER FORM
Mail this form to:
Fitted Software Tools
P.O.Box 956129
Duluth, Ga 30136
to register your copy/copies of the Modula-2 compiler and/or
register/order additional copies.
We distribute the software and documentation on 360k
floppies. A printed version of the manual is not
available.
The unauthorized distribution of the library and runtime
support source code included in the distribution disks that
you receive when you order a registered copy or update is
specifically prohibited. This source code is made available
to registered users only.
If you are ordering multiple copies for your organization,
we would suggest that you order 1 of the $35 packages and
the rest as $25 registrations. You may then distribute the
number of copies that you ordered from the master that you
receive.
Name_____________________________________________
Company__________________________________________
Address__________________________________________
City, State, Zip_________________________________
QTY
___ X Registration @ $25.00 _________
___ X Registration & latest version @ $35.00 _________
Total enclosed: _________
[We will start shipping software orders during the first
week of August 1987. We thank you for your patience and your
support.]
Table of Contents
Chapter 1 Introduction 2
1.1 Hardware requirements 3
1.2 Software requirements 3
Chapter 2 Software installation 4
2.1 Theory 4
2.2 Recommended setup for a system with 2
floppy drives 5
2.3 Recommended setup for a hard disk system
6
Chapter 3 A little tour through the system 7
Chapter 4 The Compiler 10
4.1 Running the compiler 11
4.2 The compilation process 12
4.2.0.1 The input file 12
4.2.0.2 The imported modules 12
4.2.0.3 The output file 12
4.2.0.4 A warning 12
4.3 Compiler directives 13
4.4 Runtime errors 14
4.4.1 Trapping runtime errors in your
program 14
4.5 Compiler size limits 14
4.6 The language supported 15
4.6.1 LONGINT and LONGCARD 16
4.6.2 Additional standard procedures 16
4.6.2.1 NEW and DISPOSE 16
4.6.2.2 LONG and SHORT 17
4.7 Objects exported by the pseudo module
SYSTEM 17
4.7.0.1 TYPE BYTE 17
4.7.0.2 TYPE WORD 17
4.7.0.3 TYPE ADDRESS 18
4.7.0.4 SEG and OFS 18
4.7.0.5 PROCEDURE ADR 18
4.7.0.6 PROCEDURE FLAT 18
4.7.0.7 PROCEDURE PTR 18
4.7.0.8 PROCEDURE NEWPROCESS 18
4.7.0.9 PROCEDURE TRANSFER 18
4.7.0.10 PROCEDURE IOTRANSFER 19
4.7.0.11 ASSEMBLER 19
4.8 The generated object code 20
4.8.1 Data type representation 20
4.8.2 The runtime memory map 21
4.8.3 Procedure calling conventions 22
4.8.3.1 Parameter passing (all except
open array parameters) 22
4.8.3.2 Parameter passing (open array
parameters) 22
Chapter 5 The Text Editor 23
Chapter 6 The Linker 25
6.1 Module keys 26
Chapter 7 Other utilities 27
7.1 Editor keyboard configurator 27
7.2 Map file generator 27
7.3 Make and the Makefile generator 28
7.4 The execution profiler 28
Chapter 8 The Library Modules 30
Chapter 9 Shareware 31
Chapter 10 Your input matters to us 32